An important feature of a database system is replication. Replication is the process of replicating data from a “source” database server onto another database server, herein referred to as a destination database server. As changes are made to user data on the source database server, the changes are replicated on the destination database server.
Replication is used for many database systems for various purposes. One purpose is availability. The source database server may be a primary database server and the destination database server may be a standby. If the primary database server becomes unavailable, the standby may step in for the primary database server.
Another purpose is to distribute workload between database servers. The source database server may be a primary database server that changes user data, and the destination database server may be a read-only database server that only processes queries. Alternatively, a set of database servers may switch the role of source database server and destination database server for different subsets of data. A first database server may be the primary database server for a first subset of the user data and be the destination database server for a second subset of the user data, receiving changes to the second subset of data to replicate from a second database server. The second database server, as a destination database server, receives changes to the first subset of data to replicate from the first database server.
One approach to replication is the physical replication approach. Under this approach, the changes made to data blocks on the source database of the source database server are made to replicas of those data blocks on a destination database of a destination database server. Because the source database is replicated at the lowest atomic level of storage space on the destination database, the destination database is a physical replica of the source database.
Another approach to replicating data is the logical replication approach. Under the logical replication approach, database commands that modify data on the primary system are in effect re-executed on a logical standby. Re-executing the database commands at the source database server replicates changes at the record level, but not the data block level.
Typically, changes to database systems are made using transaction processing. A transaction is a set of operations that change data. In database systems, the operations are specified by one or more database commands. Committing a transaction refers to making the changes for a transaction permanent.
Under transaction processing, all the changes for a transaction are made atomically. When a transaction is committed, either all changes are committed, or the transaction is rolled back. Because the changes are not permanent until a transaction is committed, the changes for a transaction are not replicated on a logical standby until the transaction is committed on the primary database. After a transaction is committed on the primary database server, the transactions are re-executed and committed on the source database server.
To replicate data on a logical destination database server more quickly and efficiently, transactions may be executed in parallel. Transactions may be executed in parallel by multiple processes, each process executing one of the transactions.
However, the need to preserve transaction dependency between certain transactions greatly impedes the degree or effectiveness of parallism that can be achieved. For example, if a pair of transactions includes operations that modify the same records, then the transactions are not executed in parallel. Instead, the transactions in the pair are executed in serial, with the first transaction to be committed on the primary being executed first. The transactions are serialized under these conditions to ensure that operations to the same records are committed in the same order on the replicated system as they are on the primary database server.
Based on the foregoing, it is clearly desirable to develop an approach that improves parallelism that can be achieved for replicating transactions.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.